Reviewed the client change end to end against a mock node, driving both the granted and the denied/hostile paths. The core is sound and the trust boundary is respected: a pre-supplied proof rides only the first request and does not change the retry budget (1 initial + MAX_ICAPTCHA_RETRIES), a stale token is discarded and re-solved rather than looped, a malformed proof value is rejected at header build instead of being sent, and a bogus proof grants nothing the automatic solve path doesn't since the node re-verifies the iCaptcha signature and the sub/DID binding. Requesting changes for one missing test on the new path plus two minor cleanups; none of these are correctness or security blockers.

What I verified by execution (both directions): valid proof forwards on the first request with zero solves; a bogus proof against an always-403 node stays bounded at exactly 3 requests / 2 solves, identical to the no-proof path; the retry carries the freshly solved proof, not the stale user token; Some("") sends a present-but-empty header (distinct from the omitted None path); and CR/LF/NUL in the token fail with builder error: failed to parse header value rather than being sent.

Findings

• [P3] Add a test that the proof is forwarded on the first request. crates/gl/src/register.rs:57 / crates/gl/src/http.rs:119 — the new post_with_proof -> send_signed_with_proof(initial_proof) branch ships with no coverage: all three register fixtures pass icaptcha_proof: None, and every http.rs test drives send_signed (the None path), so nothing exercises a Some(proof) value reaching the first request. A regression that dropped or mis-threaded the initial proof would stay green. A drop-in that mirrors the existing test_register_success_saves_ucan setup:

  #[tokio::test]
  async fn register_forwards_icaptcha_proof_header() {
      let dir = TempDir::new().unwrap();
      write_identity(&dir);
      let mut server = mockito::Server::new_async().await;
      let m = server
          .mock("POST", "/api/register")
          .match_header("x-icaptcha-proof", "pre.solved.token")
          .with_status(200)
          .with_header("content-type", "application/json")
          .with_body(r#"{"message":"Welcome","ucan":"eyJhbGci.test.token","trust_score":0.5,"expires":"2026-12-31"}"#)
          .expect(1)
          .create_async()
          .await;
  
      run(RegisterArgs {
          node: server.url(),
          capabilities: vec!["git:push".to_string()],
          model: None,
          dir: Some(dir.path().to_path_buf()),
          icaptcha_proof: Some("pre.solved.token".to_string()),
      })
      .await
      .unwrap();
  
      m.assert();
      assert!(dir.path().join("ucan.json").exists());
  }

  I ran this against the branch and it passes; flipping the matched header value makes it fail, so it is load-bearing.

• [P3] Document the --icaptcha-proof flag. crates/gl/src/register.rs:20 — the field carries #[arg(long, env = "GITLAWB_ICAPTCHA_PROOF")] but no /// doc comment, unlike every sibling in RegisterArgs. clap renders the field doc as the flag's help text, so gl register --help lists --icaptcha-proof <ICAPTCHA_PROOF> with an empty description. One line describing that it accepts a pre-obtained iCaptcha proof token fixes it.

• [P3] Don't report a malformed proof as a connection failure. crates/gl/src/register.rs:59 — a token containing bytes outside the header grammar fails at header build, but .context("failed to connect to node") surfaces it as failed to connect to node: ... builder error: failed to parse header value, which points the user at their network rather than their input. Reachable now that the token is user-supplied. Either validate/trim the token at the CLI boundary or give this call site a context that doesn't assert a connection error.

The rest checks out: post/put/delete are behaviorally unchanged (they delegate with None), the full gl suite stays green, and the PR body's claim that the automatic retry flow is unchanged is accurate.

I found issues that need to be addressed before this is ready.

Findings

• [P3] Add help text for the new proof flag
  crates/gl/src/register.rs:20
  The field has no doc comment, so Clap renders --icaptcha-proof <ICAPTCHA_PROOF> with an empty description (only the environment-variable annotation). This is the only CLI discovery surface for the newly added user-facing token input, leaving users unable to tell what the flag expects. Add a concise description that it accepts a pre-obtained iCaptcha proof token.

• [P3] Cover the supplied-proof registration path
  crates/gl/src/register.rs:57
  Every register::tests fixture sets icaptcha_proof: None; the existing http.rs proof test exercises the lower-level send_once helper rather than RegisterArgs -> post_with_proof. A regression that drops or misthreads the new CLI value would therefore leave the registration suite green and make the advertised workaround fail. Add a mocked registration test with Some(...) that matches the initial request's x-icaptcha-proof header.

• [P3] Do not label malformed proof input as a connection failure
  crates/gl/src/register.rs:57
  A proof containing CR/LF is rejected locally while Reqwest builds the header, before any request is sent, but the surrounding context reports it as failed to connect to node. This new user-controlled error path sends users to debug node/network connectivity instead of the supplied token. Validate the proof at the CLI boundary or use neutral request context so invalid header values are reported accurately.

I found issues that need to be addressed before this is ready.

Findings

• [P1] Do not forward a supplied proof across redirects
  crates/gl/src/http.rs:25-30
NodeClient uses Reqwest's default redirect policy, so a 307/308 response to the new initial proof-bearing POST /api/register resends the x-icaptcha-proof header to the Location origin. Reqwest only removes its small built-in authorization/cookie header set on cross-host redirects; this custom proof header (and the signed request headers) remains attached. This expands a user-supplied proof beyond the configured node and lets a redirecting endpoint expose a fresh, DID-bound proof and replayable registration request to an arbitrary origin. Disable redirects for signed/proof-bearing writes (or explicitly reject cross-origin redirects) and cover that behavior.

• [P1] Restore compilation of the existing registration tests
  crates/gl/src/register.rs:151
  Adding the required icaptcha_proof field left the existing RegisterArgs literals at lines 151, 183, and 202 incomplete. As a result, cargo test -p gl register fails to compile with E0063 before any test runs, including the new proof-forwarding test. Add icaptcha_proof: None to the pre-existing fixtures (and update any other direct initializers).